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ABSTRACT 

A  new  fonnalizatioo  of  safety  properties  is  given.  The  formalization  agrees  with  the 
informal  definition— that  a  safety  property  stipulates  that  some  '*bad  things  doesn't 
happen  during  execution — for  properties  that  are  not  invariant  under  stuttering,  as 
well  as  for  properties  that  are. 
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1.  Introdnction 

Informally,  a  safety  property  stipulates  that  some  “bad  thing"  doesn't  happen  during 
execution  [Lamport  77].  F.TJifnpiff*  of  safety  properties  include  mutual  exclusion,  deadlock 
freedom,  and  partial  correctness.  In  mutual  excbtsion,  the  proscribed  “bad  thing"  is  two 
processes  executing  in  critical  sections  at  the  same  time.  In  deadlock  freedom,  it  is  deadlock. 
In  partial  correctness,  it  is  terminating  in  a  state  not  satisfying  the  postcondition  when  execu* 
tion  is  started  in  a  state  that  satisfies  the  precondition. 

A  formal  definition  of  safety  is  given  in  [Lamport  85].  While  that  definition  correctly 
captures  the  intuition  for  an  important  class  of  properties — those  invariant  under  stuttering — 
it  is  inadequate  for  safety  properties  that  are  not  invariant  under  stuttering.  This  note  gives  a 
formal  definition  of  safety  that  is  independent  of  stuttering. 

Section  2  of  the  paper  reviews  some  notation  for  describing  properties.  Section  3  gives 
our  new  formalization  of  safety  and  relates  it  to  the  one  in  [Lamport  85].  Fmally,  section  4 
puts  our  work  into  perspective. 

2.  Properties 

An  execution  of  a  concurrent  program  can  be  described  by  an  infinite  sequence  of  states 
a  =  sqSi... 

which  we  call  a  history.  Each  state  after  Jq  results  from  executing  a  single  atomic  action  in 
the  preceding  state.  For  a  terminating  program  execution,  an  infinite  sequence  is  obtained  by 
repeating  the  final  state.  This  corresponds  to  the  view  that  a  terminating  execution  is  the 
Mme  as  a  non-terminating  execution  in  which  after  some  finite  time  (once  the  program  has 
terminated)  the  state  remains  fixed. 

A  property  is  a  set  of  histories.  We  write  ohP  to  denote  that  history  o  is  a  member  of 
property  P.  A  property  is  usually  defined  by  a  characteristic  predicate  on  histories  rather 
than  by  enumerating  the  histories  themselves.  Temporal  logic  provides  a  suitable  formalism 
for  this  purpose  [Lamport  83]. 

The  following  notation  is  used  in  the  remainder  of  the  paper.  5  is  the  set  of  states,  5* 
the  set  of  finite  sequences  of  states,  and  S'*  the  set  of  histories.  For  a  history  a  ^  jq«|..., 
define 

(t[/1  ■  J, 


(7[..i]  ■ 


We  uae  supencripts  to  denote  repetition.  Thus,  for  a  m  5  ,  a”  is  the  finite  sequence  obtained 
by  repeating  a  n  riTT¥~t  and  a"  is  tlK  history  obtained  repeating  a  indefinitely.  We  use 
juxtaposition  to  denote  catenation  of  state  sequences. 

3.  Formalizing  Safety 

If  a  “bad  thing”  happens  in  a  history,  then  it  must  do  so  in  some  finite  prefix  of  that  his¬ 
tory.  Based  on  this,  Lamport  [Lamport  85]  formalized  a  safety  property  as  any  property  P 
satisfying 

SPdP)-  (Vo;  o€5“;  a^P  o  (V/:  0:S1:  c[../]o[l]“hf>)) 

Thus,  a  safety  property  P  is  satisfied  by  a  history  a  if  and  only  if  every  prefix  of  a— extended 
to  an  infinite  M’quenge  by  repeating  its  last  state-^also  satisfies  P.  Extension  of  a  finite 
sequence  (cT[..i])  to  an  infinite  one  is  necessary  because  only  a  history  can  satisfy  a  property; 
repetition  of  the  last  step  is  one  of  a  number  of  ways  to  perform  this  extension. 

For  some  properties,  extending  a  finite  sequence  by  repeating  the  final  state  causes  prob¬ 
lems.  CnnMffer  property  CP  stipulating  that  a  variable  clock  is  increased  for  every  instruction 
exfcutrd.  Using  the  temporal  logic  notation  “O"  for  the  “next-time”  operator,  this  is  given 
by 

CP:  (clock -N)  *«»  Q(clock>N). 

Intuitively,  CP  is  a  safety  property:  the  “bad  thing”  is  clock  not  increasing  in  two  successive 
states.  However,  CP  does  not  satisfy  the  formal  definition  of  safety  given  above. 
SP i(CP)=  false  hrjany.  for  no  history  a — even  if  oHCP — will  the  value  of  clods  change  after 
the  I**  state  in  o(..i]a[l]“. 

This  difficulty  arises  only  for  properties  that  are  not  invariant  under  stuttering.  A  pro¬ 
perty  is  invariant  under  stuttering  if  and  only  if  whenever  a  history  satisfies  the  property,  the 
history  with  every  state  repeated  zero  or  more  times  also  satisfies  the  property,  and  vice 
versa.  More  formally,  any  property  P  satisfying 

SrR(P):  (if:  /€N-N:  of-P  o  <r{0/^°^^^..a[iK^')*^..|-P) 

is  invariant  under  stuttering.  Properties  that  are  invariant  under  stuttering  are  well  suited  for 
hierarchical  specification  and  verification  [Lamport  83].  By  permitting  states  to  be  repeated, 
meaningful  statements  can  be  made  about  the  system  at  various  levels  of  abstractian.  For 
example,  execution  of  a  higher-level  operatian  that  is  implemented  by  a  sequence  of  lower- 
level  operations  can  be  viewed  as  a  sequence  of  repeated,  identical,  higher-level  states  where 
there  is  one  state  for  every  lower-level  instruction  executed  but  the  last,  whidi  produces  a 
new  higher-level  state. 

We  now  give  a  formalization  of  safety  that  agrees  with  SPi  for  properties  invariant 
under  stuttering  and  that  agrees  with  the  informal  definition  of  safety  for  properties  (like  CP) 


that  are  not.  If  a  safety  property  P  does  not  hold  for  a  history  o,  then  some  “bad  thing” 
must  have  happened  during  a.  This  "bad  thing”  must  be  irremediable,  because  a  safety  pro* 
petty  requires  that  the  “bad  thing”  never  hapjpen.  Thus,  if  there  is  some  prefix  of 

o  (that  includes  the  “bad  thing”)  for  which  no  extension  to  a  history  will  satisfy  P.  Taking 
tl^  oontiapositive  of  this,  P  is  a  safety  property  if  it  satisfies 

SPADsiP)-  (V<t;  o|-/»  o  (Vi:  0:S/:  ^3:  3^5“:  a[..i] 3hf*)))- 

SPj^j^  differs  from  SP^  in  the  way  prefixes  are  extended  to  form  histories.  SP^s  pennits 
extension  using  any  history  3.  while  SP^  requires  extension  by  replicating  the  last  state  of  the 
prefix.  Note  that  SP^(CP)  =  true,  so  is  a  safety  property  according  to  this  formaliza¬ 
tion. 

TIk  relationship  between  SP^  and  SPy^os  given  in  the  following  two  theorems.  The 
first  theorem  states  that  safety  properties  under  SPi  are  also  safety  properties  under  SP^. 

Theorem:  For  any  property /*,  SPi(P)  5F^(/»). 

Proof:  Assuming  5P|.(P),  we  must  show  (Vl:  O^i:  (33:  0[../]3h^))» 

(Vi:  0:si:  (33:  3«5“:  0(..i]3hF)) 
o  (VI:  O^i;  (33:  3€5“:  a(..iia(i]>F))  5Pi(P),  since  a[..i] 3hF 
o  (Vi:  Osi:  CT(..i]0[i]“HP)  Predicate  Logie 

o  o\-P  by  SP^iP). 

□ 


Tlte  second  theorem  states  that  every  safety  property  according  to  5P^  that  is  invariant 
under  stuttering  is  also  a  safety  property  according  to  SPi- 

Theorem:  For  any  property  P,  (5PxD5(f’)^ 577? (P))  ^  SPi{P). 

Proof:  Assuming  SP/^Ds(P)  and  STR(P),  we  must  show: 

(1)  ohP  ^  (Vi;  O^i:  o'[..i]a(i]‘VP) 

(2)  (Vi:  Oii:  o[..i]o[i]>P)  -»*  ahP 

First,  we  prove  (1): 
ohP 

(•)  o(Vi:  Osi;  (33:  3  <5“:  o(..i]3hP))  by  SP^(P) 

«.(Vi:  Osi:  (33:  3«5“;  (Vn:  Osa:  a(..ila(<r  3hP)))  by  S77f(P) 
o(Vi:  Osi:  (V«:  Osa:  (33:  3  <5“:  a(../i0(/rPHP)))  by  Ptedicate  Logic 
o(Vi:  Osi:  (Va:  Osa:  (33:  3<5“:  (<Tpla(<]“)[-.<+«l3hP))) 
since  a[..i]a[iy  (a(..i]o(l]")[..<+a] 

o  (Vi:  Osi:  (yj:  l^j:  (33:  3*5“:  (0(..i)a{i]“)(-yl3hP)))  by  Ptetficate  Logic 
o(V/:  (hsi:  (Vy:  O^J:  (Sp:  3  <5“:  («F{..ij0(ini-;l3hf»))) 

since  j<l  •*»  (ff(-i]®(irOI"/l"<^(-yl  accoitfing  to  (•),  0(..y]3hP 
o  (Vi:  Osi:  a(..i]a(i]“hP)  since  5P^(P). 
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Next,  we  prove  (2): 

(V/:  (hsi:  <T[..i]CT[i]>i») 

-*»  (Vi:  (hsi:  (33:  p€S“:  fft..i]3h^))  uae3=a[i]“ 
ah^*  by  SP^sin 


4.  Disenasioo 

It  has  been  argtjed  that  properties  invariant  under  stuttering  are  the  only  ones  of  real 
interest  in  program  verification  [Lamport  83].  We  agree.  This,  however,  is  a  religious  issue. 
A  formalization  of  safety  should  serve  many  faiths.  This  note  presents  a  definition  cf  safety 
that  can  be  applied  to  any  property. 
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